Mike: Hi folks, let's talk about securing
internal network traffic.
Securing internal network traffic
is just as crucial as protecting external traffic.
By applying defense and depth principles
to internal networks,
organizations can create a robust
and layered security posture.
The key principles include implementing
a layered security approach,
adhering to the principle of least privilege,
and ensuring proper segmentation
and isolation of network resources.
When designing a defense in depth strategy
for internal networks,
several key components come into play.
Network segmentation involves dividing networks
into smaller isolated segments
based on business functions,
application tiers or security requirements.
This helps contain potential breaches
and limits the lateral movement of threats
inside your network.
Access control and authentication mechanisms
ensure that only authorized users and devices
can access specific network segments and resources.
Implementing strong authentication methods
such as multi-factor authentication,
adds an extra layer of security.
Encryption and data protection are essential
to safeguard sensitive data
as it traverses the internal network.
Encrypting data in transit
and at rest helps maintain
confidentiality and integrity.
Monitoring and logging play a vital role
in detecting and responding to security incidents.
By collecting and analyzing network logs,
organizations can identify anomalous behavior,
detect potential threats,
and take prompt action to mitigate risks.
By incorporating these defense in depth components,
organizations can significantly enhance the security
of their internal network traffic in Azure.
One of the important things to remember
as an architect is that we have moved past
this concept of creating
a moat and wall to protect the castle.
That assumes that no one can get into those things,
but what happens if they breach those outer defenses
or the external network?
We don't want to have an insecure internal network
that allows a bad actor once inside the network
to traverse any way that they want.
This defense in depth approach helps to mitigate
those types of risks
even if the external network has been breached.
Network security groups are a fundamental tool
for securing internal network traffic in Azure.
NSGs act as a stateful firewall,
allowing you to filter inbound and outbound traffic
based on IP addresses, ports and protocols.
They provide a granular level
of control over network access
at the subnet and virtual machine level.
There are several scenarios
where using NSGs are beneficial.
First is using subnet level traffic filtering,
allowing you to control access
to specific resources within a virtual network.
They also help to isolate resources
and implement micro-segmentation,
ensuring that only authorized traffic
can reach each subnet.
NSGs are also useful for controlling access
to specific services or ports.
By defining allow or deny rules,
you can restrict access to sensitive services
and reduce the attack surface.
This is particularly important
when implementing a lease privileged access model.
The network security group
is the absolute minimum standard
you should be using when trying to secure traffic
inside and outside of your networks.
Best practices define clear and consistent
naming conventions for your NSG rules
to ensure readability and maintainability.
The importance here
is that any network administrator
can look at a whole list of rules across multiple NSGs
and quickly identify whether something is missing
or whether something is there that shouldn't be there.
Implement least privilege access
to your network security groups.
It's one thing to implement an NSG
to help encourage least privilege
with your network traffic.
You also have to apply that principle
to the access of the NSG
to ensure that they are not manipulated
or controlled by any
other than those who absolutely need access.
Regularly review and update your NSG rules
to ensure they align with your security requirements
and remove any outdated or unnecessary rules.
This becomes easier when you have a clear
and consistent naming convention.
It's also recommended to use NSGs
in combination with other security controls
such as Azure firewall
or network virtual appliances
for a more comprehensive security approach.
Network segmentation and isolation
are important aspects
of securing internal network traffic in Azure.
By dividing the network into smaller isolated segments,
organizations can limit the impact
of potential breaches
and contain lateral movement.
The virtual network
is key for achieving network isolation.
By dividing VNets into subnets,
you can isolate resources
based on application tiers or security zones.
Each subnet can have its own security policies
and access controls,
ensuring that resources
within a subnet can only communicate
with authorized entities.
Your network security groups
also play that crucial role
because you can apply NSGs
to subnets or individual resources
to really get granular control
over the flow of traffic.
You can also control the flow of traffic
between the segments that you have.
Application security groups
provide an additional layer of segmentation
based on application rules.
So you group your resources
based on their application roles,
such as web servers or database servers.
And then you can apply NSG rules
specifically to those groups.
This helps to simplify security management,
but also ensures a consistent policy enforcement
across your application tiers.
When implementing network segmentation and isolation,
it's important to follow these types of best practices.
Define a clear segmentation
based on business requirements and security needs,
implement least privilege access between segments
only allowing necessary communication paths,
and regularly review
and update your segmentation policies
to ensure they remain effective
and aligned with changing requirements.
When securing internal network traffic in Azure,
it's important to consider the connectivity options
for accessing Azure services.
Two key options are service endpoints
and private endpoints.
Service endpoints allow you to secure access
to Azure services from a virtual network.
By enabling service endpoints,
you can extend the virtual network identity
to the service,
ensuring that traffic remains within the Azure network.
Service endpoints are supported
for various Azure services,
including Azure Storage, Azure SQL database,
and many, many more.
On the other hand, private endpoints
provide a private and secure connection
to Azure services.
With private endpoints,
you can expose services
through a private IP address
within your virtual network.
This ensures that traffic remains entirely
within the Azure network
and does not traverse the public internet.
When comparing service endpoints
and private endpoints, it's important to note
that service endpoints
secure access at the service level,
while private endpoints
secure access at the resource level.
Private endpoints provide
a higher level of isolation and security
as they enable private connectivity
to specific resources.
The choice between the two
depends on your specific requirements.
Service endpoints are suitable
when you need to secure access to multiple resources
of a service from a virtual network.
Private endpoints are ideal
when you require secure access
to specific resources with private connectivity
and want to ensure that traffic remains entirely
within the Azure network.
Consider factors such as the level of isolation needed,
any compliance requirements you may have,
and the granularity of access control
when deciding between service endpoints
and private endpoints
when you're securing the internal network traffic
you have in Azure.
Let's consider a real world scenario.
myHealth, a healthcare organization
is building a multi-tiered application in Azure
to handle sensitive patient data.
They need to secure internal network traffic
between application components
while complying with healthcare regulations.
Take a moment to look at the requirements here.
Pause the video,
and when you're ready to resume,
go ahead and resume it.
To meet these requirements,
myHealth can implement a defense in depth approach
by creating virtual networks
and subnets for each application tier.
From there, they can apply network security groups
to the subnets to control inter tier communication
and use application security groups
to group resources based on those application roles.
And then in doing so,
applying their NSG rules
for granular access control.
They'll want some private endpoints
for secure connectivity to Azure services,
and this will help to ensure sensitive data
remains within the Azure network
and is not exposed to the public internet.
And then enable logging and monitoring for NSGs
and private endpoints
because they'll want to know
what kind of activity is going on
in those private data sensitive environments.
They can use Azure Network Watcher
and Azure Monitor to do the detection for them.
And then they obviously want to regularly review
and update their security policies
and configurations by conducting
periodic security assessments and audits
to ensure compliance with healthcare regulations
which change rather frequently.
This is just a small slice
of what a healthcare company would do
to secure their resources,
but this is an example
of where we can start with what we've learned
and apply them to a real world scenario.
Thanks so much for being here with me.
I hope this video was helpful
and I'll see you in the next one.